خدمات شبکه

TrickBot یک تروجان جدید بانکی است که به نظر می رسد جانشین Dyre که در اکتبر 2016 پدیدار شد می باشد. کد TrickBot تحت آزمون های های پیشرونده  از آگوست 2016 بوده است و همچنان در حال بروزرسانی بوده و هم اکنون ، حمله های جعل و آلوده سازی ها. از نظر داخلی،  TrickBot بیش از چیزی است که با چشم دیده می شود. در این پست پژوهشی خدمات شبکه ما به برخی از نکات قابل توجه در مورد قابلیت های این بدافزارها می پردازیم، شامل:
•    یک روش غیر معمول انجام حملات مرد در مرورگر (MitB) 
•    مکانیسم باگ تزریق به وبِ  TrickBot  (web injection)
•    مبهم سازی ظریف رابط کاربردی برنامه نویسی(API) توسط  توسعه دهنده.
•    اعتقاد ما در رابطه با ارتباط مشکوک TrickBot-Dyre
برای تجزیه و تحلیل، نمونه ای که ما مورد استفاده قرار دادیم به شرح زیر بود: 
 5e363a42d019fc6535850a2867548f5b968d68952e1cddd49240d1f426debb73
تکنیک غیر معمول مرد در مرورگر
امروزه اکثر خانواده های بدافزارهای مالی امروزی میتوانند کد مخرب را به جلسات مرورگری که در جریان است تزریق کنند. (به عنوان مثال حملات مرد در مرورگر و تزریق به وب) رایج ترین روش توسعه دهندگان بدافزارها در پیاده سازی تزریق، نصب کردن آنها را به صورت محلی در دستگاه قربانی است. این بدافزار یک فایل پیکربندی محلی برای تزریق نگه می دارد ،که تعیین می کند دقیقا چه زمانی و چگونه بدافزار محتویات صفحات وب بانک مورد هدف را تغییر دهد. روش پیشرفته تر و غیر معمول تر برای رسیدن به نتیجه مشابه "فچ" کردن دستورالعمل نصب شبکه تزریق از سرور مهاجم در زمان واقعی است. این روشی است که توسعه دهندگان TrickBot معمولا استفاده می کنند. این روش به عنوان تزریق سرورساید (serverside)  نیز شناخته شده است.
بدین منظور و کاملا مانند دیگر تروجانهای بانکی پیشرفته، TrickBot یک موتور اتصال به مرورگر طراحی شده برای رهگیری ارتباطات به / از مرورگر اینترنت قربانی را بکار می گیرد. با ترفند فچینگ در زمان واقعی، عملا تزریق های کد های مخرب به صورت امن بر روی سرور مهاجم نگه داشته شده، نه در یک فایل بر روی نقطه پایانی قربانی. هنگامی که یک قربانی یکی از URL های مورد نظر TrickBot را در مرورگر باز میکند، اتفاقی که می افتد به شرح زیر است:
1.    ماژول مالی TrickBot پاسخ HTTP اصلی را قبل از اینکه به قربانی ارائه شود قطع می کند.
2.    TrickBot یک بسته HTTP چند بخشی به C2 خود می فرستد همراه با بخش های ذیل:
1-    "sourcelink" URL کامل که موجب این حمله می شود
2-    "sourcequery" عبارت جستجوی HTTP کامل مرورگر
3-    "sourcehtml"  HTMLاصلی همانگونه که توسط یک مرورگر غیر آلوده نمایش داده می شود.
3.    C2 با محتوای کامل HTML که به مرورگر قربانی نمایش داده میشود پاسخ داده، از جمله بخش های تزریق شده.
4.    در نهایت، ماژول مالی TrickBot جایگزین پاسخ اصلی ای که به طور معمول از بانک، همراه با پاسخ C2 به دست می آید شده، و صفحه تزریق شده در طرف قربانی نمایش داده میشود.
روش تزریق سرورساید دارای مزایای بیشتری از مکانیسم استاندارد پشتیبانی شبکه محلی استفاده شده توسط بسیاری از بدافزارهای مالی امروز می باشد. شایان ذکر است که این روش امکان ابهام و انعطاف پذیری بیشتری را می دهد. مولف این بدافزار می تواند کد تزریق را خارج از دید انظار نگه دارد تا زمانی که مورد نیازباشد. اجرا کننده می تواند تزریق وب را در حین اجرا روشن یا خاموش کند، به راحتی تزریق را تغییر دهد و سپس به روز رسانی را به برخی یا همه قربانیان آلوده بطور آنی تحمیل کند.
 

یک انتخاب عالی برای مبهم و تاریک کردن API 
زمانی که تصمیم بر زنده نگه داشتن بدافزار است، روش معمول برای نویسندگان بد افزارها اضافه کردن پسیو شبکه لایه های حفاظتی به کد خود برای دفع کردن مهندسی معکوس است. همانطور که انتظار میرود، ما یکی از فنون کار گرفته شده توسط TrickBot را شناسایی کردیم:  ایجاد ابهام در API.
پس از تجزیه و تحلیل روش ایجاد ابهام در TrickBot ، ما دریافتیم که آن بسیار شبیه - و به احتمال زیاد از قرض گرفته شده – از ایجاد ابهام در API توسط  تروجان Carberp  است. کد منبع Carberp در سال 2013 به بیرون درز شد، و باعث ظهور سایر بدافزارها بر اساس DNA پیچیده آن شد. ما متوجه شدیم که TrickBot ایجاد ابهام در API را به تمام رابط های برنامه کاربردی اعمال نمی کند؛ و  تنها بر رابط های برنامه کاربردی حساس تر که توسعه دهنده می خواهد تا پنهان شوند اعمال می کند. این یک روش مرموز است، چرا که محققان ممکن است باور داشته باشند که در حال حاضر تمام رابط های برنامه کاربردی استفاده شده را می شناسند، اما در واقع رابط های برنامه کاربردی بیشتری وجود دارند که بطور مخفیانه بخشی از بازی اند. روند ایجاد ابهام در اینجا بر اساس مقادیر "هش" از قبل محاسبه شده ی رابط های برنامه کاربردی اند. فراخوانی یک تابع API فقط شامل یک مقدار هش به جای نام تابع است، و تجزیه و تحلیل استاتیک را دشوارتر می سازد، مگر این که محقق روش کمکی دیگری برای حل و فصل رابط های برنامه کاربردی اعمال کند.
  

شکل 4: حل یک API توسط هش - WSAStartup.

یک راه ساده برای غلبه بر این ایجاد ابهام استفاده از یک دیس اسمبلر تعاملی  (IDA)  اسکریپت پایتون می باشد، به این علت که مقادیر هش شده خودشان در کد منبع به بیرون درز شده ی Carberp موجود می باشند.
 
پدیدار شدن باگ
TrickBot از تابستان 2016 تحت آزمون بوده است. حتی قبل از آن مجهز به ویژگی های بدافزارهای مالی بوده است. در ابتدا، توسعه دهندگان TrickBot به نظر می رسد با مکانیسم تزریق وب بدافزار درگبر بوده اند، چرا که ما با چند نمونه TrickBot روبرو شدیم که به طرز عجیبی رفتار غیرقابل پیش بینی شده ای ارائه دادند. در ابتدا، ما مشکوک شدیم TrickBot از برخی حیله های ضد پژوهش استفاده می کند، اما در واقعیت، مشکل این بوذد که آلوده شده بودند. طبق بررسی های ما، سوء عملکرد تزریق وب TrickBot باعث می شد که بدافزار به طور مداوم همان کابل کشی شبکه را بارها و بارها تزریق کند، که منجر به تخریب عملکرد خود، بدافزار می شد. از آنجایی که این رفتار در برخی از نمونه ها ناسازگار بود، ما باید به صورت دستی یک ثابت اعمال می کردیم تا بتوانیم به تحقیق درباره ی مکانیزم ادامه دهیم. ما نمی خواهیم به جزئیات بیشتری در این زمان در این باره بپردازیم، چرا که این اشکال در واقع مانع انجام اختلاسهای TrickBot شد. با این حال ما میدانیم که از آنجایی که بدافزار در حال توسعه مداوم است، توسعه دهندگان ممکن است در حال حاضر این اشکال را مورد بررسی قرار داده باشند و آن را در نمونه های جدیدتر درست کرده باشند، و TrickBot را قادر به عملکرد هموارتری کرده باشند.
اتصال TrickBot-Dyre 
به محض اینکه تروجان کشف شد، حدس و گمان هایی در مورد ارتباط TrickBot-Dyre پدید آمد و از آن زمان موضوع بحث های زیادی بوده است. اگر چه این موضوع در چند وبلاگ دیگر در خصوص بررسی TrickBot ذکر شد ما می خواهم چند نکته کلیدی از تحقیقات خودمان در مورد این تهدید جدید اضافه کنیم:
•    روش تزریق وب سرورساید  در TrickBot در بدافزارهای امروزی غیر معمول است. دیگر بدافزاری که از آن استفاده می کرد، همان طور که شما می توانید حدس بزنید، Dyre بود. 
•    بسته هایی که در طول تزریق وب سرورساید  به سرور حمله ارسال میشد شامل سه قسمت، با عنوان "sourcelink"، "sourcequery" و "sourcehtml" بود. این اسامی دقیقا در مکانیسم تزریق وب Dyre نیز استفاده می شد.
 

•    URL های هدف قرار داده و آدرس های فرمان و کنترل (C & C) نگهداری می شوند و بر روی دستگاه آلوده رمزگذاری می شوند. Dyre نیز چنین عملکردی داشت. در حالی که طرح های رمزگذاری با TrickBot یکسان نیستند، بیش از حد شبیه اند که بخواهیم آن را یک تصادف صرف تلقی کنیم.
•    TrickBot لیست URL های مورد نظر را به ماژول مالی خود ، که به مرورگر با استفاده ارتباط pipe تزریق  می شود می فرستد. این، دوباره، مشخصه ای از مشخصه های  Dyre است.
•    ساختار URL های مورد هدف در تنظیمات معمولا برای هر بدافزار ثابت است و مشخصات هدف  TrickBot – همانطور که حدس می زنید - کاملا به  Dyre شباهت دارد.
اگر چه تشابهاتی وجود دارد، در نظر داشته باشید که بسیاری از آنها نسبتا به سادگی قابل تقلید هستند. به عنوان مثال، اگر چه روش تزریق وب سرورساید  بین هر دو تروجان مشترک است، اما کد اجرای این قابلیت و سبک رمزگذاری عملا متفاوت است.
اهمیت این مطلب این است که می توانیم بفهمیم که بدافزار های جدید و پیشرفته پسیو شبکه به سرعت و به طور موثر در حال توسعه اند، چه توسط همان توسعه دهندگان همیشگی و چه توسط تازه واردان الهام گرفته از یکی از باندهای نابکار در تاریخ جرایم اینترنتی.
به روز رسانی دقیقه نود: حملات تغییر مسیر!
توسعه دهندگان TrickBot گویا این روزها برای ارتقای بدافزار برای یک آلوده سازی به صورت زنده با هدف بانک ها سخت مشغول کار باشند. درست هنگامی که در صدد انتشار این پست بودیم، یک آلوده سازی جدید با تنظیمات جدید که بانکهای انگلستان را مورد هدف قرار داد را شناسایی کردیم. تا به حال، TrickBot تنها بانک های استرالیا هدف قرار داده بودند. علاوه بر این، برخی از این اهداف جدید انگلیسی مورد حملات تغییر مسیر قرار گرفتند، در حالی که  تا به حال TrickBot تنها به دست به حمله های تزریق وب سرورساید زده بود. حمله تغییر مسیر، بطور خلاصه، به این معنی است که به جای تزریق کد های مخرب به صفحه وب اصلی، قربانی به یک سایت جدید جعلی توسط کلاهبرداران هدایت می شود. این سایت دقیقا مانند وب سایت اصلی به نظر می رسد و مرورگر یک اتصال لایه امن سوکت (SSL) بر اساس گواهی سایت اصلی نشان می دهد.
برای کسب اطلاعات بیشتر در مورد حملات تغییر مسیر و هدف آنها، به وبلاگ ما در مورد Dridex و GozNym سری بزنید.
یک تازه وارد به عرصه تروجان
TrickBot بدون شک کار حرفه ای هایی است که مدتی است در عرصه تروجان بانکی فعالیت داشته اند. این کلاهبردارانِ با تجربه، ظاهرا در ویژگی های مدرن معمول در انواع بدافزار هایی که بانکها می توانند متصور شوند مهارت دارند. انتظار می رود که این تروجان تکنیک های ضد امنیتی و ضد پژوهشی اش را تکمیل کند و در آلوده سازی های بیشتری تا پایان سال ظاهر شود..

 

ما در نقطه ی جالبی از دوره شالوده ابری هستیم. دیتاسنتر های مدرن پسیو شبکه در حال تغییر از شکل فیزیکی به مجازی است، پشته های مدیریتی متعددی به لایه ی مجازی یا logical وارد می شوند. آیا تغییر دیگری در دیتاسنتر در حال وقوع است؟ آیا انواع جدید پلتفرم های کامپیوتری اجازه ی ایجاد مدل بازتری از دیتاسنتر را می دهند؟ اکنون شاهد تغییری در روش ارائه ی خدمات مراکز اطلاعاتی هستیم. یک نوع  جدید commodity در حال راه یابی به ارائه دهنده گان ابر به مشتری و حتی مراکز اطلاعاتی ارائه دهنده ی سرویس است.

به مشتریان انتخاب های بیشتری در مورد آنچه استفاده می شود و روش کنترل آن داده می شود. با در نظر گرفتن تمام این مسائل، مهم است که بدانیم پلتفرم های سرور commodity در ساختار ابری شما چه تاثیری می گدارند.


سرورهای commodity و ابر Bare Metal

با این که بحث در این مورد اخیرا بیشتر شده است، جعبه ی سفید و commodity از چند ارائه دهنده ی خدمات شبکه مراکز اطلاعاتی یک حقیقت است. ما در یک مقاله ی اخیر در مورد DCK به سرور های Rackspace پرداختیم که مانند VM های ابری عمل می کنند. این ابزار که OnMetal نامیده می شود، سرورهای ابری ارائه می دهد که سیستم های تک کاربره و bare-metal هستند.

میتوانید از طریق OpenStack سرویس ها را در چند دقیقه تامین کرده و با سرورهای ابر مجازی دیگر ترکیب کنید و انتقال سرویس را با نیازهای شخصی تنظیم کنید . شما در اصل می توانید سرورهای خود را بر اساس حجم کار یا نیازهای کاربردی خاص خود طراحی کنید. 

اهمیت دارد که به این امر توجه شود که Rackspace در این فضا تنها نیست. Inteap و SoftLayer که اکنون یک شرکت IBM است سرورهای metal قدرتمندی ارائه می دهند. سرورها نیروی خامی را که شما برای حجم کار  processor-intensive  و disk IO-intensive  خود نیاز دارید را برآورده میکند.

از انجا، شما می توانید سرور خود را از طریق یک پرتال یا API برای ویژگی های خاص خود تنظیم کنید و در زمان واقعی پشتیبانی شبکه بر روی هر دیتاسنتر  SoftLayer بکاربرید. با در نظر گرفتن تمام این مسائل، میزان تنظیم bare metal که می توانید در ابر Softlayer داشته باشید بسیار چشمگیر است. ذخیره سازی، حافظه و uplinks شبکه، منابع نیرو، GPU ها و همچنین آرایه های ذخیره سازی توده ای را می توان تنظیم نمود. شما حتی میتوانید یک رک (rack) فیزیکی با تنظیمات شخصی داشته باشید. 


پلتفرم های ابری بعنوان Commodity 
فروشنده های سرور بزرگ حتما این پیام را شنیده اند. ارائه دهندگان ابر، مراکز اطلاعاتی و سرویس همگی به دنبال یافتن راههای بهتری برای کنترل عملکرد، قیمت و پلتفرم های رایانشی هستند. پس چرا وارد میدان نشویم و کمک نکنیم؟ اخیرا HP و Foxconn یک کار مشترک را برای ایجاد خط جدیدی از سرورهای بهینه سازی شده نصب شبکه را بویژه با هدف قرار دادن ارائه دهندگان سرویس آغاز کردند. بنا بر بیانیه ی مطبوعاتی، این خط تولید جدید بطور ویژه نیازهای رایانشی بزرگترین ارائه دهندگان سرویس جهان را از طریق ایجاد هزینه ی کل مالکیت (TCO)، مقیاس دهی و سرویس و پشتیبانی پایین برطرف می کند.

این خط پورتفولیوی سرور ProLiant موجود HP  را که شامل Moonshot می شود تکمیل می کند. هدف این است که نرم افزار بهمراه نوآوری های صوتی و تصویری حذف شود و در عین حال پشتیبانی HP حفظ شود. از انجا، این سرورها سرویس دهندگان بزرگ را برای کمک به مبارزه با مشکلات مراکز اطلاعاتی موبایل، ابر و Big Data هدف قرار می دهند.

مساله ی جالب در مورد سرورهای HP Cloudline این است که آنها سیستم های رک-مقیاس (rack-scale)هستند که برای بزرگترین خدمات شبکه مراکز اطلاعاتی ابری بهینه سازی شده و بر اساس استاندارد های صنعت باز ساخته شده اند. فروشندگان در جامعه ی فروش نیز انتخاباتی را ایجاد می کنند. سلوشن های ذخیره سازی از X-IO Technologies برروی عملکرد کاملا خالص با ظرفیت 100% تمرکز دارند. آنها دسترسی و افزونگی بالا در خود دارند، اما امکان تصویرلحظه ای، dedup، replication, thin provisioning و چند ویژگی های ذخیره ای در سطح نرم افزار را ارائه نمی دهند. اما یک وارانتی پنج ساله بر روی دستگاه وجود دارد.

البته بازهم جاهایی وجود خواهند داشت که این کار امکان پذیر نخواهد بود. اما برای تعداد زیادی از سازمانها حرکت به سوی یک پلتفرم ذخیره سازی که بطور منطقی تر کنترل می شود بسیار جالب است. در بعضی موارد هایپروایزر یا لایه ی ذخیره سازی نرم افزاری تعریف شده میتواند ویژگی های ذخیره سازی سازمانی مثل رمزدهی، dedup  را بصورت مستقیم از لایه ی کنترل مجازی ارائه دهد.
 

اکوسیستم های ابری آینده انواع بیشتری خواهند داشت
رشد رایانش ابری امکان ایجاد تنوع بیشتری را در پلتفرم دیتاسنتر ایجاد کرده است. اکنون ما انتخاب های بیشتری برای میزبانی، توانایی بالاتر برای انتقال و پشتیبانی بیشتر از سیستم های قوی در سراسر دنیا داریم. کاربرد سیستم های bare metal و commodity systems بدون شک افزایش خواهند یافت.  با کمک گرفتن از مفاهیم جدید در اینترنت اشیا و تحرک، مراکز اطلاعاتی تنها باید از کاربران بیشتری پشتیبانی کرده و اطلاعات بیشتری را حمل کنند.

به خبر اخیر تامین کننده خدمات  Cisco توجه کنید: بصورت جهانی 54 درصد گوشی های موبایل تا سال 2018 دستگاه های پسیو شبکه هوشمند خواهند بود که از21 درصد در 2013 افزایش یافته است.تا 2018 اکثریت ترافیک اطلاعاتی موبایل (96 درصد) از این گوشی های هوشمند منشا خواهد گرفت.مانند هرچیز دیگری در تکنولوژی، ما شاهد تغییر سیستم ها برای براورده کردن نیازهای مدرن خواهیم بود. فروشندگانی چون Cisco, HP, Dell وغیره- که در بازار سرور سنتی تر عمل می کنند-باید در هماهنگی با سازمانهایی که بدنبال رویکردهای کالایی به ساختار دیتاسنتر هستند تغییر کنند.

وقتی سازمانهای جدید با  مشکلات جدیدی در زمینه ی انتقال ابر و محتوا روبرو می شوند، انتخاب های بیشتر طراحی و ساختار این عملکرد را تسهیل می کنند. در بعضی موارد تنها نیروی خام بدون نواوری های نرم افزاری مورد نیاز است. با کمک سلوشن های نرم افزار تعریف شده و مجازی سازی به جداکردن لایه ی logical از پلتفرم فیزیکی این امر با مصداق بیشتری می یابد.

ما اکنون می توانیم منابع را کنترل کنیم، ترافیک را رهیابی کنم و از هایپرویزور و ابر کاربران را مدیریت کنیم. این امر به سخت افزار زیرساخت اجازه ی تمرکز کامل بر روی انقال منابع را داده و لایه ی مدیریت را در جای دیگری قرار می دهد. 

با وجود چشم انداز تهدیدات که بطور فزاینده ای پیچیده تر می شوند، اکثر سازمان ها (89%) تنها از سلوشن های امنیتی  IT بسیار ساده استفاده می کنند.
این ادعا بر اساس گزارش خطرات IT 2017 نتریکس (Netwrix)، که به این نتیجه رسیده که 74% از سازمان ها اعتراف کرده اند که در برابر خطرات IT مصون نیستند، می باشد.
اکثر سازمان ها (89%) سلوشن های امنیتی IT را محدود می کنند، و تنها 13% از پاسخ دهندگان خدمات شبکه از از سلوشن های پیشرفته تر برای مدیریت خطر و اداره امنیت اطلاعات استفاده می کنند. تنها 58% از پاسخ دهندگان کنترل فناوری اطلاعات فعلی خود (و یا عدم آنها) را برای نیازهای خاص سازمان خود کافی میبینند.
موانع اصلی برای اصلاح این موضوع، کمبود بودجه (57٪) و کمبود وقت (54٪) می باشد- در حقیقت، 65% از سازمان ها پرسنل اختصاص داده شده برای امنیت سایبری ندارند. انطباق نیز به همین وضع است – 56% از سازمان های تحت انطباق این وظیفه را به تیم های عملیاتی IT محول می کنند. با وجود اینکه 65 درصد از پاسخ دهندگان به داشتن حوادث امنیتی در سال 2016 اقرار کرده اند، اما این مشکل همچنان پای برجاست. شایع ترین دلایل ذکر شده خطاهای نرم افزارهای مخرب و انسانی بود. همچنین، 66% از سازمان ها، کارکنان را بعنوان بزرگترین تهدید برای دسترس بودن و امنیت سیستم می دانند، اما تنها 36% از سازمان ها ادعا می کنند که بطور کامل از اعمال کارکنان آگاهی دارند.